Method and apparatus for providing symbolic mode checking of business application requirements

ABSTRACT

A system and method for providing symbolic mode checking of business application requirements. A language allows for building a model for the business process, the model comprising a plurality of actions, with each action having a precondition and a postcondition or outcome. Specifications are constructed for the properties of the business application, with the specifications describing both the states of the business process and the order in which they may occur. Finally, the model and the specifications are analyzed to determine if the model satisfies the specifications. If the model fails to satisfy the specifications, a problem may be indicated in the business application. The process can be automated to permit the system to make assumptions for conducting a thorough analysis of selected potential problem areas in the application.

The present application claims priority to co-pending U.S. Provisionalapplication 60/307,190 filed Jul. 23, 2001.

FIELD OF THE INVENTION

The invention relates generally to the field of business applicationsand more particularly to a method and apparatus for performingpreliminary checking of business application models to detect potentialdefects.

BACKGROUND OF THE INVENTION

Business applications have gained widespread use, despite theircomplexity and the difficulty in accurately projecting theirperformance. Businesses use applications for tasks including reimbursingemployees for travel expenses, ordering notebooks and other officesupplies, allocating office and cubicle space, and other routine trivia,as well as for more complex tasks such as the bookkeeping andorganizational procedures by which on-line auction houses organizeauctions, banks handle checks, insurance companies decide what sort ofpolicy to issue, railroad companies track trains' locations andcontents, etc. Business applications need to be flexible in ways thatmore typical, linear computer programs do not. As an example, a businessapplication which automatically processes employee travel vouchers mustbe capable of evaluating a plurality of contingent conditions (e.g.,employee status, employee travel allocations, expenditure ceilings,approval requirements, etc.) and of processing or routing requests basedon the evaluation of those conditions. Further, business applicationsnecessarily rely heavily on human action, such as when human judgment isessential to a resolution of an atypical transaction. Well-designedbusiness systems have escape commands in which privileged users (e.g.,managers) can “violate” the general requirements and invariants of thesystem as necessary in order to deal with reality.

For preliminary diagnostic purposes, with the intent of eliminating“bugs” during software design, it is desirable to create models of thesoftware which demonstrate where problems may occur in the finishedproduct. Due to the nature of business applications, the behavior offully-developed business applications is somewhat unpredictable andtends to be difficult to model. Nonetheless, given the fact thatbusiness applications are expensive to develop and use, and generallyeven more expensive to retrofit when bugs have been detected after theapplications are in use, it is prudent to evaluate the applications inthe early design to locate detectable defects by modeling the behaviorof the application. The desire for detecting defects is realisticallyoffset by the practicalities of modeling. Clearly not all behaviors canbe checked unless the entire application is executed, which would be aprohibitively lengthy and intensive modeling process.

Model checking is a preferred method for formally evaluating thebehavior of a business application. In model checking, such as isdetailed in the publications entitled Model Checking by E. M. Clarke, etal , MIT Press, (Cambridge, Mass., 1999) and Model Checking LargeSoftware Specifications by N. Carriero, et al, IEEE Transactions onSoftware Engineering, pages 498-519 (July 1998), a system is describedas a finite-state model and a desired property of the system isexpressed as a logical formula. Having the finite-state model and thelogical formula, it can be determined whether the system has the desiredproperty. While computationally complex applications cannotrealistically be fully modeled, due to exponential expansion of thepossible decision paths, many useful cases can be analyzed.

Ordered Boolean Decision Diagrams (OBDDs) have been a very successfulapproach to model checking, providing a compact canonical notation forBoolean expressions, in which all the basic operations are efficientlycomputable. The model must be phrased as Boolean formulas, for example,with the state s as a vector of Boolean variables, formulas St(s)describe the possible start states, and Trans(s,t) describing when thesystem can take a transition from s to t. The multi-step behavior of thesystem can then be computed from these (e.g., the set of reachablestates is computed from the transitive closure:

{r |∃s .St(sTrans(s,t)}.

Temporal logic formulas (e.g., Computation Tree Logic or CTL), can alsobe expressed as OBDDs. Checking whether or not the model satisfies theformula then becomes a matter of calculation. In many useful cases, OBDDcalculations can be done quickly. This approach has verified propertiesof system with astounding numbers of states, currently up to 10¹²⁰ forwell-designed systems and properties. Model checking with such systems,however, takes a significant amount of human work in setting up theproblem. Therefore, while model checking has theoretical potential inmany arenas, it has primary usefulness in the areas of protocol checkingand circuit checking, wherein the models are inherently small and ofregular structure. Model checking has had limited applicability inchecking routine software.

With regard to software checking, model checking has been used not forverification but for so-called falsifying of properties, whereinselected bugs in the system can be targeted and found. For example, onemay see if a protocol can deadlock or a memory management chip can losea page. Clearly, these are important properties to identify and correct,Checking a handful of well-chosen properties can catch many errors, andcan increase confidence that remaining errors are scattered and morebenign. Some properties, however, may simply be too hard to check.

Additional shortcomings of model checking include the fact that themodels must be kept as small as possible, due to the fact that even abit or two in the wrong place can greatly increase computation time. Byreducing model size, however, one necessarily sacrifices some degree ofcertainty that the model is adequate for its checking purposes. It mustalso be recognized that the real system (i.e., the business applicationbeing checked) is must larger than the model and that verification viathe model which concludes that an application does not produce errors inits execution of four consecutive processes cannot predict that theapplication will not lock upon execution of the fifth process.

Therefore, it is desirable, and is an object of the present invention,to provide a method and apparatus for checking a business applicationfor detectable defects in the early application design using modelchecking.

It is another object of the invention to provide a method and apparatusfor applying model checking for verification of selected aspects ofbusiness application software.

Yet another object of the invention is to provide a method which gives atotal, programmatic description of classes and activities of a businessapplication as well as a partial, logical description of specificationstherein.

SUMMARY OF THE INVENTION

The foregoing and other objectives are realized by the present inventioncomprising a system and method for determining if a business processsatisfies certain properties, the method comprising building a model forthe business process, the model comprising a plurality of actions eachhaving a precondition and a postcondition, constructing specificationsfor the properties which describe both the states of the businessprocess and the order in which they may occur, and determining if themodel satisfies the specifications, wherein failure to satisfy thespecifications indicates that the model (and the underlying businessapplication) is problematic and requires some modification.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in greater detail with specificreference to the appended drawings wherein:

FIG. 1 illustrates a chart of quantifiers which can be used with thepresent invention;

FIG. 2 illustrates the conversion from the inventive language to SMV;

FIG. 3 illustrates a process flow for implementing the inventiveprocess; and

FIG. 4 illustrates a process flow for specifying a business process inthe inventive language.

DETAILED DESCRIPTION OF THE INVENTION

To model business applications, it is first to be recognized thatbusiness software tends to be very data-driven. A great manyhuman-computer interactions involve recording data, entering names andaddresses on applications, recording boxes of supplies received atloading docks, etc. The program's decisions, and the decisions that itpresents to users, are typically conditioned on data. For example, atravel reimbursement for less than $100/day might be automaticallyaccepted and paid, whereas a more expensive one might need a manger'sapproval, and one for $1500/day might require a series of approvals athigher management levels.

Partially as a consequence of this, under the present invention,business data is multiply, dynamically categorized. Multiplecategorization models the fact that a person might be an employee or acustomer, both, or neither. Dynamic categorization captures the factthat a person can be hired or fired. Standard object models, evenmultiple inheritance models, don't capture this every well, sinceemployee and customer cannot usefully be made subclasses of person inmost programming languages. Nonetheless, experience suggests thatmultiple dynamic classification is a good way to think about anddescribe business data.

Business data can be described by Classes and Aspects. The Classesclassify information such as person, employee, customer, male, female.Aspects group mutually exclusive sets of classes, for exampleperson.gender includes male and female, and models the fact that a givenperson can be at most only one of the two at any instant. An aspect withonly one element represents an option: for example, person.employmentdenotes the single aspect employee. An object may have classes indifferent aspects at the same time, such that a given person may be bothan employee and a male.

Changing one class may trigger changes to others, for example firing anemployee involves removing their employee classification. If x is amanager (and hence an employee), firing him removes his managerclassification as well as his employee classification. Conversely,hiring someone to be a manager turns them into an employee as well.

Business decisions are generally guided or constrained by thecategorization. Insurance policies have different behavior dependingupon the gender, marital status, etc. A travel reimbursement form mighthave classifications including Submitted, Approved, Paid, which maytrack the progress of the form through the process, and LowPrice,NormalPrice, HighPrice, based on the amount being sought. When the formis Submitted and NormalPrice, it will be given to a Manager forapproval; and, upon approval, will be switched to the Approvedclassification.

Models of business application have been built (cf:1S010746-2,1S010165-7) for explanation but not implemented. A systemconsists of a data model and a control model. Data is a collection ofobjects, together with some relationship between them. The objects arein a multiple dynamic classification hierarchy, they have many classes,and they can change classes as the application proceeds. The runningexample of the travel invoice processing system will be used as anexample:

//Define a classification for travel forms... class TravelForms //thestatus of a form tells where it is //in the approval application aspectstatus : TravelForm; classSubmitted,Approved,Rejected:TravelForm.status; //The cost of a formtells whether the amount //being asked for is reasonable. aspect cost :TravelForm; class LowCost,MediumCost,HighCost: TravelForm.cost;

Once a form is Approved, it may at some point be Paid:

aspect payment: Approved; Class Paid : Approved.status

Note that it is impossible for tf to be both Paid and Rejected. Paid isa subclassification of Approved, and Approved and Rejected are mutuallyexclusive.

The model also permits mappings (partial or total functions) and generalrelationships between entries. For example, a suitable definition ofsets of objects TRAVELFORMS and PEOPLE is assumed. In some systems,these will simply be all entities of type TravelForm and Person.

//Relationship: who submitted the form? map submitter: (TRAVELFORM ->PERSON, partial; //Relationship: management rel manages : PERSON*PERSON; //Also keep track of who approved what rel signedOffOn :TRAVELFORM -> PERSON;

Control consists of a collection of activities, running asynchronously.An activity represents some agent (human or automated) using asubsystem, such as: a manager using the application to approve travelforms, a program evaluating applications and routing them to the correctpeople, and so on. Activities may correspond to highly abstractedversions of large subsystems (e.g., invocations of legacy applications).

Activities have preconditions under which they can execute and haveoutcomes. Outcomes perform some computation, thereby changing entityclassifications and relationships. An activity may have several outcomesand some agent, human or computer, will choose one of the outcomes eachtime the activity is executed. Activities are assumed to be atomic, andnon atomic events can be modeled as sequences of activities. Forexample:

act judgeTravelForm (tf: TRAVELFORM, subm :PERSON appr: PERSON)  pre  (tf :MediumCost)& (tf: Submitted)   & (submitter(tf) = subm   &(manager(appr,subm))  pick   outcome DoAcceptance :>    now tf :Approved, signedOffon(tf, appr);   outcome DoRejection :>    now tf :Rejected;  end-pick end-act

The judgeTravelForm activity applies to submitted, medium-cost travelforms. Once the traveler fills out the form, the result is an entity tfwhich is in state Submitted and MediumCost. When that happens, theactivity may fire (i.e., proceed to the next step). Other activities maybe enabled as well, of course. When an activity fires, one of two thingswill happen: the travel form may be approved with appr recorded as theone who approved it, or it may be rejected.

There is no explicit sequencing between activities; however,preconditions can provide implicit sequencing since one set ofactivities can wait for a condition that another one sets.

Once the model is defined, specifications may be added. The system willtest them, and will report either that they are true or will give a(partial) counterexample. For example, it may be desirable that, if atravel form has not already been rejected, it might eventually be paid,as shown below:

spec outcomeIsAlwaysPossible:>  always, all tf: TF.  !(tf:Rejected)->(somehow eventually tf:Paid);

The foregoing general style of model, allowing some flexibility in thedetails, has been quite useful in describing business application. Thedescriptions are quite abstract, describing data and computation fairlycoarsely (for example, the actual cost of the trip will not be recordedat this point in the modeling). This methodology emphasizes recordingthe important criteria, the distinctions upon which the decisions are tobe made, while suppressing details that will not be relevant until laterin the implementation.

The model is good for describing business applications in a reasonablelevel of detail. The description can serve as a specification of thesystem, and can be a basis for a more detailed analysis. The act ofdescription has value, for it forces people to think about their needsand requirements in detail.

The description of a complex system in necessarily inadequate since itis hard to understand or predict how the system as a whole will behave.The single-step behavior from a particular state is easy to understandsince it is clear which activities and outcomes will fire (i.e., if A,then B). However, the multi-step behavior can be difficult to model(i.e., if A, then B or C or D; and if B, then Q, if C then R, and if Dthen S). Using the example of an online auction system, it is recognizedthat one activity may allow an administrator to stop an auction at anytime, which is a crucial capability, particularly since an auction housemust be able to deal summarily with illegal or immoral auctions. Otheractivities allow buyers to pay sellers on-line and for sellers todeliver digital auction items on-line. As an example, it would beunreasonable to have a system-wide requirement that an item must bedelivered once paid for, since there may be instances (e.g., death of aseller) where such is unreasonable. It would be reasonable, though, tohave a system requirement that the system not prevent a seller fromsending a payed-for item.

Clearly the requirements in the foregoing examples, if formalized in themost obvious way, are inconsistent. If the administrator stops theauction after the buyer has paid and before the seller has delivered,then the seller cannot deliver. Such an issue is not hard to addressonce it has been identified. However, identifying it by looking at thespecification for the application can be quite difficult, particularlybecause the relevant activities are only a few among dozens of candidatescenarios and are widely separated in terms of definition andanticipated reaction/result. Therefore, the foregoing is bestcharacterized as a temporal specification, to wit, “If the buyer haspaid and the seller has not delivered, then it is possible that theseller eventually delivers”. Note that the delivery need not be enabledat that instant, it must simply be possible at some future time.

It is, therefore, proposed that specifications at this level ofdevelopment of the application are good subjects for model checking forthe following reasons: fairly abstract models can be done at a size anddegree of formality which is technologically suitable for symbolic modelchecking; the model of computation which is most suitable for describingbusiness application is data-driven; and, model checking of businessapplication specifications can occur early in the “lifecycle” of theapplication, thereby allowing for relatively easy and inexpensivecorrection. Since model checking research has largely focused oncircuits and protocols, current languages are largely tuned for thosedomains. Therefore, a new language is needed which is aimed atdescribing business application in terms with which business applicationmodelers are familiar. The language is constrained in ways that ensurethat all specifications are finite state programs and thus checkablemodulo resources which can be checked against CTL specifications or canbe executed by hand in an interpreter.

The modeling language consists of definitions of data and activities,plus some specifications which should be checked. Data comprisesentities and relationships. Entities are statically described as amultiple dynamic classification hierarchy, with classification andaspect definitions as detailed above. Object is the built-in root class;Object.sub is a built-in aspect of it used for subclasses in the objectorientation (OO) sense. To illustrate:

class Person, Auctionable :Object.sub: aspect age, job, online: Person;class Adult : Person.age;  // x is a child if x is not an adult classBuyer, Seller, Admin: Person.job; class On; Off: Person.online.

Entities must be declared explicitly, with permanent and initial classesgiven. This declares a Person, an Adult and Buyer who is initiallyOff(line). That person will stay an Adult and Buyer forever, but theonline status may change. For example:

Entity Arwen: Adult, Buyer:=Off;

Entities may be grouped into domains, which are static structures usedfor abstraction. Domains can overlap and be heterogeneous. Toillustrate:

Domain BUYER = (Arwen, Eleri) Domain ADULT = (Arwen, Huw, Cefyn);

It is occasionally useful to have things in domains which are notentities, but which can be used in relations and maps, as shown below:

nonentity CardiffBay; MountSnowdon; domain WELSHTHING =(Arwen, Eleri,Huw, Cefyn,  CardiffBay, MountSnowdon);

The ordering of elements in a domain is significant. It is to be notedthat entities do not have attributes or properties. Data aboutindividual entities is expressed as classifications and data relatingseveral entities is expressed as relations and maps. Relations and mapsare essentially mutable versions of the mathematical constructs. Toillustrate:

rel owns: (PERSON, AUCTIONABLE);  init (Arwen, CarvedSpoon);defines the relationship owns, which will be used to model who ownswhat. Initially Arwen owns a carved spoon, though this may change as thesystem computes. Relations may be declared to be reflexive, irreflexive,symmetric, and/or unchanging. All of these declarations save bits in themodel checker, and provide useful invariants that are automaticallyenforced. For example:

rel nextTo: (PERSON, PERSON)  irreflexive, symmetric;describes who is next to whom. Nobody is next to themselves (hence therelation is reflexive); and if one person is next to another, the otheris next to the one (hence it is symmetric).

Maps model total or partial functions, such as:

map owner: AUCTIONABLE->PERSON;

which is one way to say who currently owns what. Maps may be partial,unchanging, initialized, or have symmetries between selected sets ofarguments, as shown below:

map spouse: PERSON->PERSON, partial;

The expressive language of the invention is tuned for writingspecifications for modeling of business applications. The primitiveexpressions are directly related to the kinds of data:

p = On // True iff p is logged on      //(vix., if p has class On) P ! :Buyer//True if p is not the Buyer owns (p,q) //true if p owns q owner(q)= p //true if the owner of q is p spouse(p) = undefined //true if p hasno spouse p= Arwen //true if p is Arwen

Domains are ordered, and the order can be queried. Since objects canbelong to several domains, and may be in different orders in differentdomains, the domain of comparison must be specified. Comparisons alsomay be chained, as shown below:

p<Arwen<=q IN PEOPLE

Boolean expression are the heart of business applications, expressingthe conditions under which an activity is available, or the requirementson the system, and can get quite complex. The Boolean operations for thepresent invention are designed to cut down on parentheses, redundantsubexpressions, and visual ambiguity.

Six Boolean combinators are used, including &, |, ->, and <->, forconjunction, disjunction, implication, and equivalence, as is usual inmany systems. The others are n-ary operations: ÂB̂Ĉ . . . ̂Z is true whenprecisely one of A,B,C . . . , Z is true, and A#B#C# . . . #Z is truewhen at most one of them is true. These frequently need to be said inspecifications, and are hard to say compactly and readably with only thestandard operations.

Boolean implication and equivalence are not associative operations. Theinventive language has a nonstandard but useful meaning for iterated ->and <->. A->B->C is interpreted as (A->B) & (B->C), and similarly for<->. This allows specifying nested predicates, e.g., saying that thehigh bidder in an auction must have made some high bid in that auction,and that in turn means she has looked at the auction, as shown below

highBidderIn(b,a)->hasBidIn(b,a)->hasLookedAt(b,a)

Expressions of the form A & B | C look ambiguous. They are not ambiguousin any actual computer language, but it can be hard to remember whichoperation takes precedence, or which way it associates if neither takesprecedence. It would be even harder to keep track of precedencerelations among the six combinators. The inventive language does notallow this sort of visual ambiguity:A & B | C is syntactically illegal.(A & B) | C and A & (B | C) are legal, of course.

However, this could easily lead to masses of parentheses, unambiguousbut confusing. The issue is addressed in two ways. First, braces { } andbrackets [ ] are allowed, as well as parentheses. Second, and moreinterestingly, there are three precedence levels of the Booleanoperations. && and &&& are conjunction, like &, but with medium and lowprecedence. So, A && B | C is allowed, and means A & (B | C), and A & B∥C means (A & B) | C. A && B ∥ C is illegal, just as A & B | C is. Thelow precedence operations are useful in long conditions, which usuallyconsist of several joined clauses. To illustrate:

  item : MediumPrice | item : LowPrice    // It's cheap &&& I ! :BoughtSomething    // I haven't bought anything yet &&& I : LowOnCash-->    item: LowPrice| have (I, GiftCertificate)    // I can afford it!

These syntactic tools, if used with common sense, allow users to writecomplex Boolean expressions reasonably readably, without too manyparentheses or ambiguous-looking clauses.

The invention also allows quantifications over domains, to wit:

(all x in PEOPLE, x: AWAKE).

Since domains are finite and fixed at compile time, quantification is aconvenience rather than a qualitative necessity. There are fivequantifiers, as are shown in the chart in FIG. 1, including some, all,no, one, and at-most-one. Quantifiers may work on subsets of theirdomain. For example:

one x: AUCTIONABLES such that owns (p,x), forSale(x) holds when exactlyone auctionable item owned by p is for sale.

Quantifiers allow multiple variables, ordered or unordered. For example:

no x !+ y: PERSON, x:HighBidder & y:HighBidder

holds when there are not two people marked as HighBidder.

Comparisons, with respect to the domain of quantifications, may be usedas well. For example:

some x<y: PERSON, canWorkTogether (x,y)

holds if and only if some pair of distinct people can work together. Aquantifier with != would mean the same, but would induce an expressionwhich would be twice as long.

There are activities which represent agents interacting with subsystems,typically making decisions. Each activity has a precondition, and a bodyof code. The body of code may include choices between several outcomes.Many things may be done at the same time, with the body being considereda sequence of transactions, each done atomically. The distinctionbetween sequential and simultaneous composition is made very explicit.

Instantaneous commands are considered to happen atomically, as ifexecuting inside a transaction. A great deal of computation can happeninstantly with the present invention. The now command modifies entities'classifications, and maps and relations.

now Arwen: On // Change Arwen's class now Huw!: Adult // Remove Huw'sAdult class now nextTo(Arwen, Huw); // set a relation now !nextTo (Huw,Eleri); //remove a relation now owner(CarvedSpoon)=Huw; // change a mapnow spouse(Huw) = undefined; // Divorce Huw;

Looping and conditional branding have a fairly familiar syntax.Instantaneous commands may be executed simultaneously, modulocontradictions; with * (or “together-withs”) being used as the operatorfor simultaneous composition. So, when two people get married, they stopbeing married to everyone else. For example:

now married(x,y) * for z = PERSON do   if z != y then now !married(x,z)fi   *   if z != x then now !married(z,y) fi rof

Note that all the changes to married, including those from the differentiterations of a loop are simultaneous. A single for can represent nestedloops over related variables over the same domain. For example:

for x<y: PERSON do now !nextTo(x,y) rof

moves everybody apart. Just as for quantifiers, it avoids repeated work,since each distinct pair is only considered once, and pairs where x=yare not considered at all.

Choices made by agents describe the possible transitions of the system.This models, for example, presenting the user with a form, and buttonsmarked “APPROVE” and “REJECT”. Some outcomes may be conditional, suchthat the APPROVE button may only be usable when the travel form iswithin corporate guidelines. Outcomes are named by way of documentation.Hence:

pick   outcome APPROVE when travelForm:MeetsGuidelines :>     nowtravelForm:Approved   outcome REJECT :> now travelForm:Rejected;end-pick

The inventive system only allows one choice to be made at a time. Anactivity can include several picks, separated by the sequencingoperation AND-THEN. Sequencing is somewhat more expensive thansimultaneous composition, so the invention provides a somewhat longersyntax for that.

Activities have preconditions which describe when they can be performed,plus bodies which are commands to be performed.

act logOn(p: PERSON)   pre p !: On;   pick     outcome successfulLogon:> now p:On;     outcome failedLogonAttempt :> skip;   end-pick end-act.

When the system is running, the activity is enabled when theprecondition evaluates to true for some instantiation of the formalparameters with entities from the suitable domains. The rest of theactivity is a sequence of instantaneous commands and pick commands,which may be executed as above. Only one activity will fire at a time.

Specifications are statements in branching temporal logic. The systemchecks each specification, printing a message that it is true, or hintsat a counterexample when it is false. The semantics describe a programas a forking tree of states. At each state, some set of activities canfire. Each outcome of each enabled activity induces a transaction toanother state.

The specification language uses CTL connectives to explore the tree.Each temporal modality has two parts. The first part quantifies over theset of possible next states; the second part is a temporal connectivelike “eventually”. CTL traditionally uses single letters for modalities.Background research suggested that few businessmen were instantlycomfortable with “EF” and “AG”, therefore a more verbose but suggestivesyntax is employed.

The branching component of a modality is either surely (CTL's A) orsomehow (CTL's E). The temporal component may be henceforth (CTL's G),eventually (CTL's F), next (CTL's X), until (CTL's U), or until-maybe (aweak until, a derived operation in CTL). For example:

spec CarvedSpoonCanBeBought :>   somehow eventually, some p:PERSON    hasBought (p,CarvedSpoon);specifies that it is possible on some computation path (EF) to find astate where the carved spoon has been bought. Similarly,

spec NobodyFixesCarvedSpoonIfTheyStartBroken :>   CarvedSpoon:Broken ->    (surely henceforth CarvedSpoon:Broken);says that, if the carved spoon starts out broken, it will stay that wayon all computation paths for all time (AG). There are also twocombination modalities: forevermore=AG=surely henceforth, andpossibly=EF=somehow eventually.

The inventive system and method also allows always as a synonym for AG,but only as the outer more temporal modality. Always is useful forspecifying invariants. It is not allowed, however, in nested modalities,because it causes confusion whereby “always” is misinterpreted to mean“for all time, past as well as future” instead of the correct “for allfuture time”. For example:

spec NobodyEverFixesCarvedSpoons :>   // inner ‘always’ is illegal  always (CarvedSpoon:Broken->     always CarvedSpoon:Broken);was misinterpreted as implying that if the carved spoon ever broke, ithad to have been broken from the beginning.

spec NobodyEverFixesCarvedSpoons :> //this is OK   always(CarvedSpoon:Broken->     forevermore CarvedSpoon:Broken);The words “henceforth” and “forevermore”, though stilted, at least havefewer wrong connotations.

Temporal connectives may be nested. The example ofNobodyEverFixesCarvedSpoons is a typical nesting for a monotonicityproperty; once a certain fact (CarvedSpoonBroken) has been established,it remains true forever after. Other nestings are useful as well, asshown below:

spec SubmittedFormsCanGetPaid :>   always, all f:TravelForm,    f:Submitted & f !: Rejected -->       (possibly f:Paid);says that, in any state in which a travel form has been submitted, andhasn't been rejected, there is some computation path which can lead toit getting paid.

The travel form example is one of the smallest useful businessapplications which can readily be used as an example. One person, thetraveler, fills out a form after going on a trip. His manager mustapprove or reject it. The manager may pass the form along to themanager's manager instead. The top manager of the organization cannotpass the form further along, of course.

The travel form object is described as follows. It has states includingFilledOut, Submitted, Approved, and Rejected. The states Approved andRejected are implemented as subclasses of the state Submitted because aform can only be approved or rejected after it has been submitted. Toillustrate:

class TravelForm : Object.sub; aspect filledOutNess. Status :TravelForm; class FilledOut : TravelForm.filledOutNess class Submitted :TravelForm.status aspect status : Submitted; class Approved, Rejected :Submitted.status;

The two aspects are connected by an invariant, if a form is approved, itmust be filled out, such that:

spec onlyFilledOutFormsAreApproved :>   always, all tf:TF, tf:Approved-> tf:FilledOut;

People, too, are given a very small description, they are eithermanagers or not for this exercise. For an example, there are fourpeople, as shown below:

class Person : Object.sub; aspect management : Person; class Manager :Person.management; entity Arwen : Person := Person; entity Bran : Person:= Manager; entity Cefyn : Person := Manager; entity Dafyd : Person :=Manager; domain PERSON = (Arwen, Bran, Cefyn, Dafyd);

The actual management hierarchy is expressed as a relation, as shownbelow:

rel manages : (PERSON, PERSON), irreflexive,   init (Bran, Arwen),(Cefyn, Bran), (Dafyd, Cefyn);

Additionally provided is an invariant which ensures that only Managersactually manage people. It has been found to be extremely valuable towrite this sort of invariant to explain the intended meaning of thepieces of the model. Accordingly,

spec onlyManagersManage :>  always all p: PERSON,   (some q:PERSON,manages (p,Q))-->p:Manager;

Travelers are then connected to travel forms, as shown below:

domain TRAV = [Arwen, Bran]; //Persons who travel entity tfa :TravelForm := TravelForm; entity tfb : TravelForm := TravelForm; domainTF = [tfa, tfb]: // Their travel forms. rel owns : (TRAV , TF);  init(Arwen, tfa), (Bran, tfb);

After a form has been submitted, someone will judge it. Thisrelationship has an invariant as well, since at most one person may bejudging the form at a given time. Accordingly:

rel judging : (PERSON, TF); spec onlyOneJudge :>  (surely henceforth,all tf:TF,   at-most-one p : PERSON,    judging (p, tf));

Travel forms may be filled out, as characterized below:

act fillOut(p : TRAV, tf : TF)  pre tf !: FilledOut;  now tf :FilledOut; end-act;

Further, once the travel forms are filled out, they may be submitted tothe traveler's Manager, as follows:

act submit (p : TRAV,tf:TF, mgr, PERSON)  pre tf : FilledOut && owns(p,,tf)   && tf !: Submitted && manages (mgr, p);  now tf:submitted,judging(mgr, tf); end-act;

The conjunct tf !: Submitted prevents a form from being submittedrepeatedly.

An auxiliary relation is used to represent the act of one manager“passing the buck” to another manager. The term confusedBy (Bran, tfa)indicates that Bran has just given up on travel form A in confusion andthat Bran's manager Cefyn must now judge the form. The term:

rel confusedBy: (PERSON, TF);

shows the buck passing.

The main activity of the application is when some manager mgr judgessome travel form tf. This can only happen when the manager is the onejudging the travel form, and when no judgment has been made on the form.The manager may choose to approve or reject it, or choose to pass thebuck. However, people who have no managers cannot pass the buck,therefore, the confusing outcome has an extra test, as shown below:

set judge (mgr : PERSON, tf : TF)  pre judging(mgr, tf) && tf !:Approved    & tf !: Rejected: pick  outcome good :>   now !judging(mgr,tf), tf: Approved  outcome bad :>   now !judging(mgr, tf), tf: Rejected outcome confusing   when (some sup : PERSON, manages(sup,mgr)) :>   now!judging(mgr, tf), conductedBy(mgr, tf);  end-pick end-act;

When one person is confused by tf, then that person's manager must picktf up and start working on it. Simultaneously, the confusion flag isturned off. To illustrate:

act pickUp (mgr : PERSON, tf:TF)  pre (some p: PERSON)   (manages(mgr,p) & confusedBy(p, tf)));  now judging(mgr,tf);   //these two thingshappen at once.  for q : PERSON do   now !confusedBy(q,tf): //unconfuseeveryone  rof end-act.

At this point, a number of useful specifications are possible. Furtherprogram invariants may be asserted, such as that nobody issimultaneously listed as judging and confused by a form, and that nobodyshould ever judge their own form. This is conveniently expressed withthe “at most one of” operation #, shown below:

spec onlyOneUseOfForm:>  [surely henceforth, all p: PERSON, all tf:TF,  owns (p,tf) # judging(p, tf) # confusedBy(p, tf)];

A more crucial property of the system is that it never gets stuck. Realapproval systems have been known to violate this property. Specifically,it should always be the case that a travel form can get approved orrejected, as is shown below:

spec formsCanAlwaysGetDealtwith :>  (surely henceforth,   all tf:TF,   somehow eventually.     tf:Approved | tf:Rejected     );

It is also useful to have specifications to check intuition.Specifically, in the running example, while it seems obvious that the“buck” can be passed, it must be actually possible and the specificationshould test to make sure that the top manager might have to deal withthe form. For example:

spec maybeDafydHasToDoIt :> (somehow eventually, judging(Dafyd, tfa));

The inventive approach to specifications has been applied to coveraspects of program behavior including a few variants, and a fewproperties for diagnosis. As the model was being developed in testing,several times a specification was violated. Violation of a specificationcan indicate any one of the following: that there is a problem in thebusiness process, such as a missing precondition on an activity; thatthere may be a problem in the specification itself, indicating a problemin the specification writers' understanding of the business applicationbeing evaluated; or, that there was a false positive which indicatesthat the business process is incomplete.

Working with the model checker gives a sense of confidence in thebusiness process. Ordinary business process models give only a singledescription of the business process. The present model provides both atotal, programmatic description of classes and activities and a partial,logical description of specifications. Getting the two descriptions toagree reveals a number of bugs and omissions. While the finalapplication may still have some undiagnosed bugs and omissions, there issome assurance that the system will at least exhibit some desirablebehaviors in spite of bugs.

Also, model checking provides a useful form of regression testing. Oncea problem has been identified and solved and recorded as a spec, thesystem will continue to test it as the system evolves. So, the problemwill either stay solved or the system will alert the user that it has“become” unsolved again.

The example also allows system exploration. For example, if a personnelsubsystem is added, which allows hiring, firing, promotion, anddemotion, it must be recognized that several of these functions willbreak the travel reimbursement process. In the running example, if Cefynis demoted at the same time that Bran is confused by a travel form, thetravel form could fall between the cracks. The system specs will detectthe problem so that when organizational structure changes, suitablemeasures can be taken to update unfinished processes.

The so-called Strix inventive language has been implemented only astylluan, a version of which was written explicitly for the invention yettranslates correctly back to tylluan. The differences are largelysyntactic (e.g., tylluan does not have chained variables in quantifiersor multiple picks in a single activity). The system has astraightforward parser written in javacc; the parsed program istranslated to SMV, and run through the existing SMV model checker.

SMV is a BDD-based checker. Described herein are only the features whichare used, and the SMV language description is mixed with the descriptionof the translation. An SMV program consists of a number of modules, eachof which declares some variables, and describes a part of the transitionrelation. Scalar variables may have Boolean or symbolic values from somefixed set; variables can also be instances of modules.

The inventive classes become SMV modules, used to aggregate data. SMVhas no inheritance, so each class becomes a distinct SMV module, withlocal variables for each bit of data that the class might need. Forexample, the inventive language/process translates the person type by amodule cls-person, with variables for the person's management andimportance. These variables range over codes for all the subtypes in themanagement and importance aspects of person (e.g., the manager class isrepresented here by id-person-management-Manager-and another value forthe case that the object has no classification in that aspect). Modulestake formal parameters which are used to provide the initial values ofthese variable. Each module defines a part of the state-transitionrelation. The init( . . . ) assignments provide initial values for thevariables; next( . . . ) assignments describe how variables change stateacross transitions. To illustrate in code:

MODULE cls-Person (formal-Person-management, formal- Person-importance)VAR  v-Person-management : (none-Person-management,  id-Person-management-Manager)  v-Person-importance :(none-Person-importance,   id-person-management-VIP); ASSIGN init(v-Person-management) := formal-Person- management  next(v-Person-management) := v-Person-management;  init(v-Person-importance)  := formal-Person- importance; next(v-Person-importance) := v-Person-importance

Instances of classes are declared as variables of the main program,initialized suitably. For example:

VAR  Arwen : cls-Person (none-Person-management,          None-Person-importance)

System activities are converted to SMV modules used asasynchronously-parallel subprocesses. One transaction for the filloutprocess looks like the following:

MODULE proc-fillOut (tfa) DEFINE  precond :=tfa.v-TravelForm-filledOutNess=id- TravelForm-filledOutNess-FilledOut;ASSIGN  next (tfa.v-TravelForm-filledoutNess) := case   precond :id-TravelForm-filledOutNess- FilledOut;    !precond:tfa.v-TravelForm-filledOutNess; //***   esac;

The DEFINE clause names an expression. The case expression is aconditional expression, taking the first branch whose condition is true.

There is no separate concurrent composition construct in SMV. Concurrentprocesses are module instances marked by the process keyword, as shownbelow:

VAR p-filledOut-tfa: process proc-filledOut(tfa)

As an additional complexity, the parameters of an SMV module are boundat compile time, not run time. Therefore, an instance of each SMVprocess must be started for each possible assignment of arguments. ThefillOut activity takes a TRAV and a TF as arguments, so |TRAV|X|TF|process instances will be needed. The translation can thus get extremelyexpensive, creating vase numbers of processes very quickly.

Each instance of each outcome of an activity defined by the inventivelanguage/process turns into a separate SMV process. Therefore SMVfairness constraints are needed saying that each activity is allowed torun infinitely often. (Note that, if an activity's preconditions are notsatisfied, running the corresponding SMV process does not changesanything, see the *** line above.

Each relation is implemented by a module, the manages relation by therel-manages module. In code:

MODULE rel-manages VAR  at-Arwen-Bran: boolean;  // ...  at-Bran-Arwen:boolean;  // ... ASSIGN  init (at-Arwen-Bran)  :=0;  next(at-Arwen-Bran)  :=at-Arwen-Bran;  //...  init(at-Bran-Arwen)  := 1; next) at-Bran-Arwen) := at-Bran-Arwen;

The relation module is used entirely for holding data. Queries on therelation become SMV accesses to members: manages(Bran-Armen) becomesmanages.at-Bran-Arwen, and changes to the relation become assignments tomembers. Note that each vector of arguments costs one bit. Thereflexivity and symmetry conditions eliminate possible vectors ofarguments (e.g., sorting them, so that married(Bran-Arwen) andmarried(Arwen-Bran) would be stored as at-Arwen-Bran), and thus conservebits. Unchanging relations are compiled away completely.

Basic expressions become the natural calculations on SMV data (e.g.,tf:approved becomes(tf.v-Submitted-status=Id-Submitted-status-Approved)). SMV has many ofthe boolean connectives which are used above. The others can beprogrammed (e.g., ÂB̂ĈD is translated as !(A&B) & !(A&C) & !(A&D) &!(B&C) & !(B&D) & !(C&D) & (A|B|C|D), where the last clause requiresthat at least one of the expressions be true, and the others say that notwo are true.

Quantifiers are expanded. The inventive domains are fixed and known atcompile time. For example, suppose DOM=[a,b,c], (all x: DOM, p(x)) willbe translated as (p(a) & p(b) & p(c)). The translations for one andat-most-one are quadratic, as are the translations of ̂ and #.

Both languages uses CTL as their underlying temporal logic. Translationof temporal modalities is mostly a matter of turning surely into A andhenceforth into G. The inventive language has the weakuntil-p-until-maybe q holds when p remains true until q first becomestrue, or forever if q never becomes true-but that is easily expressed inCTL. Each of the inventive specifications therefore becomes one SMVspecification. The conversion is illustrated in pseudo-code in FIG. 2with the inventive language being referred to as STRIX.

When SMV determines whether a spec is satisfied or not, it prints outthe first few characters. It also prints out a counterexample forunsatisfied specs. Since an SMV program may have many specs, and sincethe specs that SMV uses may look quite different from the inventivelanguage forms, in extreme case, the first few characters of the SMVspec may be all “(”s—a module is defined called “spec” with constantsfor each specification name, and include that constant as the firstconjunct of the specification:

MODULE spec DEFINE onlyManagersManage := 1;

Model checking engines are based on NP-hard problems, and are quitesensitive to their inputs. Adding an entity or an activity may increasethe running time from a few seconds to a few hours to a few eons.Experience with the language has lead to a number of programmingpatterns that sometimes can turn it back from hours to seconds.

Each vector of possible arguments to an activity generates one SMVprocess. So, the number of processes can be as bad as the product of thesizes of the domains. The language does no compile-time analysis, if theprecondition of an activity instance can be determined to be false, thenit does not generate a process for it. It is generally worth cuttingdown on the number of formal parameters to an activity. The “confusedBy”relation, with the pick Up activity that it triggers, is programmaticway to avoid a third argument in the judge activity. In the travel formexample with four people, the three-argument version takes about twiceas long. Similarly, a for loop is used to turn off confusedBy(q,tf) forall possible “confuses” q, rather than mentioning the one person who wasactually confused as an argument.

SMV does not simply calculate whether a spec is true or false. If it isfalse, SMV attempts to produce a counterexample, in the form of a traceof the system execution which violates the spec. Some specifications, ofcourse, do not have counterexample traces. For example, a counterexampleto forevermore x:Blue is a trace leading to a state in which x is notBlue, but no single trace is a good counterexample for possibly x: Blue.

SMV also produces counterexample traces in terms of SMV variables andprocesses. The translation scheme is as transparent as possible, suchthat the name of the SMV process is built from the name of and bindingof the inventive language process.

The inventive checking process is applied by the process flow which isillustrated in FIG. 3. The first step, at 301, is building a model forthe business process, the model comprising a plurality of actions eachhaving a precondition and a postcondition. Next, specifications for theproperties which describe both the states of the business process andthe order in which they may occur are constructed at step 302 (furtherdetailed with reference to FIG. 4). With the model and specifications inplace, the final step is determining if the model satisfies thespecifications, wherein failure to satisfy the specifications indicatesthat the model (and the underlying business application) is problematicand requires some modification. The determination is made at decisionbox 303. If the specifications are satisfied, as indicated by the YESresponse, then the process exits at 304. If however, the specificationare not satisfied, as shown by a NO out of decision box 303, then aproblem is indicated to the user/system by notification in step 305. Inan automated version of the system, discussed below, a series ofiterations may be conducted with variations on the model or thespecification being invoked to more definitively locate the source ofpotential problems.

FIG. 4 provides a process flow for specifying a business process. Atstep 401, objects are described using a dynamic, multi-classificationmodel as detailed above. At step 402, the system describes actions thatcan take place in terms of the classifications of the potential objectsused in the action. Next, it is described, at step 403, how theclassification of objects may change during actions (e.g., the buckpassing example). Finally, an application is generated that ensures thatactions take place when valid, at step 404. Clearly, once the languagefor the business application has been specified, one can utilize that asa precondition for performing model checking, as well as for writing theexecution engine for the application.

The invention provides the language for modeling business applicationsand the process for specifying the business process. Additionally, theinvention provides the process for using model-checking technology toverify temporal-logic specifications. The language is tuned for theissues and concepts of relevance to high-level business analysis. Whilethe inventive language is not a general-purpose programming language,the programs are executable, either with or without user intervention.The language interpreter will have panes to show the classificationhierarchies and relationships of all the entities, and a list ofactivities and their outcomes that can fire. This lets the user executeand explore the model. For extra ability to explore, the interpretershould allow saving and restoring system states, and going backward aswell as forward.

One embodiment which is particularly desirable is doing simulationrunning the program automatically, making random choices of activity andoutcome. If the activities and outcomes are annotated by costs andprobabilities, the program can be run without human intervention and thecost of the process can be estimated. The simulator should be quiteefficient, making hundreds of runs per second, accumulating statisticsabout the system's costs and bottlenecks.

The invention has been described with specific reference to severalpreferred implementations. It is to be understood that modifications canbe made without departing from the spirit and scope of the invention asset forth in the appended claims.

1-12. (canceled)
 13. A method for a computing system having at least oneprocessing device for checking a business process for operating on aplurality of objects, said process being capable of attaining aplurality of states, comprising the steps of: identifying objects ofsaid process using a dynamic multi-classification model; determiningactions that can take place in said process in terms of theclassifications of the objects used in said actions; evaluating how theclassification of objects changes during actions; and determiningwhether selected states of the business process are reachable based onsaid actions. 14-17. (canceled)
 18. A program storage device readable bymachine storing a program of instructions executable by said machine forperforming a method for checking a business process for operating on aplurality of objects, said process being capable of attaining aplurality of states, said method comprising the steps of: identifyingobjects of said process using a dynamic multi-classification model;determining actions that can take place in said process in terms of theclassifications of the objects used in said actions; evaluating how theclassification of objects changes during actions; and determiningwhether selected states of the business process are reachable based onsaid actions. 19-20. (canceled)